One thing we want to do for the next versions of GNOME and Fedora is to improve battery performance. Your laptop may well be advertised by the manufacturer to have “up to 10 hours of battery life” or some such claim. You probably don’t get anywhere near this.
Let’s put out some rough numbers here to give an overall sense of scale for the problem. For a modern ultrabook:
- The battery is 50 watt-hours (Wh) – it can power a load of 50W for an hour or a load of 5W for 10 hours.
- The baseline idle consumption of the system – this is RAM refresh, the power consumption of peripherals in power-saving mode, etc, is 5W.
- The screen and keyboard backlights, if both turned on to 100%, draw 5W.
- The CPU/GPU can sustain about 15W – this is a thermal limit, so it can draw more for short bursts, but over time it will be throttled to an average.
- All other peripherals (Wifi, bluetooth, touchpad, etc.) can use about 5W of power combined when not in power-saving mode.
So the power draw of the system can range from about 5W (the manufacturer’s 10 hours) to 30W (1 hour 40 minutes). If you have such an ultrabook, how is it doing right now? I’d guess it’s using about 15W unless you pay a lot of attention to power usage. Some of the things that might be going wrong:
- Your keyboard/screen backlights are likely higher than is needed.
- Some of the devices on your system don’t have power-saving turned on properly.
- You likely have some background CPU activity (webpage ads, for example).
Of course, if you are running a compilation in the background, you want your CPU to be using that full 15W of power to get it done as soon as possible – in this case, your battery isn’t going to last very long. But a lot of usage is closer to idle.
Measuring power usage
I’ve made assertions above about power used by different things. But how did I actually measure that? powertop is the state of the art for measuring power usage and tweaking it on Linux. It will show you a figure for current battery discharge rate, but it bounces around by several watts; partly because powertop’s own data collection loads the system. The effect of a kernel option is usually much smaller than that. One of the larger effects I discovered on my laptop was that turning USB autosuspend for the touchscreen saves about 150mW. When you tweak a tunable in powertop, without a way to measure power usage more accurately, it’s hard to know whether any observed differences are real.
To support figuring out what is going on with power, I wrote gnome-battery-bench. What it does is pretty simple – it plays back recorded sequences of events in a loop and monitors battery charge to estimate power usage. Because battery usage is being averaged over minutes, a lot of the noise is averaged out. And the event sequences can be changed to exercise different usage patterns by the user.
The above screenshot shows gnome-battery-bench running a “Light Duty” benchmark that combines scrolling around in a Wikipedia page and typing in gedit. Instantaneous usage bounces around a lot from the activity and from random noise, but after a few cycles the averaged power and estimated battery lifetime converge. The corresponding idle power usage is about 5.5W, so we see then know that we’re using about 2.9W from the activity.
gnome-battery-bench is designed as a graphical application because I want to encourage people to explore with it and find out interactively what is using power on their system. And graphing is also useful so that the user can see when something is going wrong with the measurement; sometimes batteries will report data that jumps around. But there’s also a command line version that can be used for automatic scripting of benchmarks.
I decided to use recorded sequences of events for a couple of reasons: first, it’s easy for anybody to create new test sequences – you just run the gnome-battery-bench command line tool in record mode and do what you want to test. Second, playing back event sequences at a low level simulates user interaction very accurately. There is little CPU overhead, and as far as the desktop is concerned it’s exactly like user input. Of course, not everything can be easily tested by simply playing back canned sequences, but our goal here isn’t to test everything, just to be able to test some things that are reasonably representative.
The gnome-battery-bench README file describes in more detail how it works and how to install it on your system.
Next steps
gnome-battery-bench is basically usable as is. The main remaining thing to do with it is to spend some time designing and recording a couple of sequences that better reflect actual usage. The current tests I checked in are basically just placeholders.
On the operating system, we need to make sure that we are actually shipping with as many power-saving options on for peripherals as can be supported. In particular, “SATA link power management” makes a several-watt difference.
Backlight management is another place we can make improvements. Some problems are simply bad defaults. If ambient light sensors are present on the system, using them can be a big win. If not, simply using appropriate defaults is already an improvement.
Beyond that, in GNOME, we can optimize application and system code for efficiency and to not do things unnecessarily often in the background. Eventually I’d like to figure out a way to have power consumption also tracked by perf.gnome.org so we can see how code changes affect our power consumption and avoid regressions.
fishsoup 
22 Comments
Glad to hear that you are interested in doing this and involving GNOME is tracking power consumption regressions and reducing power consumption in GNOME as a whole.
I use powertop a lot for finetuning battery usage, and setting the brightness to the lowest required, I managed to get out a 5+ hours battery life from my Asus TP500LN, with wifi on, browsing, coding and occasionally compiling the code.
I will check my power usage with gnome-battery-bench, with normal usage, to see what’s the result.
This looks great.
Should consideration be given to a baseline measurement that ignores all DE particulars? Perhaps running the battery test without any DE? That way we can see what overhead is introduced by various DE utilities.
The main desktop dependency in gnome-battery-bench is actually just the recorded event scripts. While the simplest “idle” test script would work on any desktop, actual navigating between applications and doing stuff in them will differ significantly between desktops and the same keystrokes won’t work. So it’s hard to do an exact comparison. My expectation – tests could prove or disprove it! – is that the idle usage will be pretty much identical between desktops, modulo backlight settings. It’s the power usage when things are actually going on which will differ.
Even Gnome fails a bit when using a non-English keyboard layout. My layout has hyphen where the application expects slash, so some of the simulated web browsing doesn’t work.
For Watt-hour, please use Wh or W⋅h. http://en.wikipedia.org/wiki/Kilowatt_hour.
Indeed; upper-case H is the henry, the SI unit of inductance: http://en.wikipedia.org/wiki/Henry_(unit)
OK, fixed in the blog and in the code.
I wrote a simple Python script a while ago that samples the uevent file of the battery every few seconds (BMS doesn’t update faster anyway) and stores the samples in memory (to avoid disk I/O). Measurements usually converged quickly (less than four samples) for idle power consumption, which is probably most interesting for most people – me at least.
I’d agree that for some types of measurements – even for my example of the effect of USB autosuspend for a touchscreen – you can get good numbers quickly if you get as much noise as possible of the way and do an isolated measurement. But my long term interest is in measuring the battery consumption under typical desktop usage… for that this overall approach works better. I also hope to “democratize” things here a bit – to make something that is usable without a lot of setup.
> I also hope to “democratize” things here a bit – to make something that is usable without a lot of setup.
Indeed, I’m very happy that you’re developing this ; juggling around with sysfs and matplotlib is certainly not something every “energy-conserving user” is willing or able to do 🙂
By the way, forgot to mention it earlier, there is quite some tolerance on the data provided by the BMS, especially with older ones. Older BMS (from ten+ years ago or so) often suffer strong thermal drift, so measurements with a hot / not in thermal equilibrium battery are often somewhat meaningless. The current, and thus power, accuracy is also not very great (+- 2-3 %, depends on exact model and controller), but voltage is accurate to at least <0.2 %.
This is however not too relevant for this kind of measurement, since "less is more" and it's more about a general feeling for power consumption rather than really accurate numbers.
Hello, saw this linked from LWN and had a go at using it. The things that went wrong were (on Fedora 21, Thinkpad Yoga):
– asciidoc is not given as a dependency, I did’t have it so make failed.
– invoking gnome-battery-bench fails because the helper is not started.
Error calling CreatePlayer: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
– starting /usr/libexec/gnome-battery-bench-helper as non-root fails without any warning message.
– starting /usr/libexec/gnome-battery-bench-helper with sudo and then running gnome-battery-bench causes the helper to die (“Can’t create uinput: No such file or directory”). From gdb the die seems to originate from the libevdev_uinput_create_from_device() with uidev_keyboard.
Thanks for trying it out!
* There’s supposed to be an asciidoc configure test – I’ll have to try removing asciidoc from my system and see why it’s not working properly.
* The helper should have been started by the DBus daemon. Is /usr/share/dbus-1/system-services/org.gnome.BatteryBench.Helper.service present? Do you have any errors in your system logs?
* The uinput problem sounds like you might not have uinput configured on your system or udev isn’t set up properly to make the device nodes. I’d have imagined this would be present on most recent distributions, but I’ve only tested with Fedora 21. What distribution are you running?
Thanks, it is working. I didn’t have uinput configured in my kernel. The dbus service entry was present, the service just exits because of the missing uinput. Great! 7 hours on idle.
“There’s supposed to be an asciidoc configure test – I’ll have to try removing asciidoc from my system and see why it’s not working properly.”
There’s empty value in (docs/)Makefile:477, so:
GEN gbb.xml
/bin/bash: -f: command not found
happens. Didn’t read comments first so it took me a while to get that asciidoc is needed.
Anyway, I failed with getting it run. I moved some files manually and created some dirs, as there were “no such file or directory” errors. Right now I stuck on:
./src/gnome-battery-bench
** (gnome-battery-bench:30782): WARNING **: Duplicate test ID idle
** (gnome-battery-bench:30782): WARNING **: Duplicate test ID lightduty
Error calling CreatePlayer: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.BatteryBench.Helper was not provided by any .service files
and for now I give up. It’s probably another “move helper file to right directory” task, but I have very little knowledge about Gnome apps, so I give up (any suggestions welcome).
Software looks very interesting (thx for creating it!), so I’ll keep an eye for updates/comments.
I’ve now pushed changes to a) fix building without asciidoc b) give somewhat more informative output if uinput isn’t enabled – the gnome-battery-bench application itself now exits and prints out “Error calling CreatePlayer: Can’t open /dev/uinput: No such file or directory. The kernel may not be compiled with uinput support.”
(A dialog from the application would be even better – I’ll eventually go ahead and add it.)
rozie: I’m not really sure what’s going on on your system. All the necessary directories will be created automatically if they aren’t there. It seems like you’ve gotten things into a confused state by trying to install manually. Feel free to find my on #fedora-workstation on freenode IRC and I’ll help you sort it out.
You probably realize this, but just to make sure:
g-b-b doesn’t change the locale (kbdmapping) to the one used when the test was recorded so it may end up doing slightly different things in other locales: e.g. on my machine the “light duty” test ends up doing web searches for “aboutöblank” — so the load is somewhat different from what was intended.
Ouch – it is sort of painful. I don’t like the idea of changing the user’s settings – if gnome-battery-bench crashes or is killed by the user they’d be left with a wrong value. But the alternative of trying to figure out what physical hardware keys we need to press to get the desired output is quite technically challenging. With XKB it’s not simply “this key with these modifiers gives this key symbol” – there’s a whole state machine being maintained. Changing the keyboard settings temporarily is certainly easier. I’ll have to think about it.
Hi,
I had trouble getting results as my sysfs does not have energy_now. I made some small changes so that this works better also with charge_now (also fixed a typo in if clause). What is the proper way to submit patches? I’d be happy to submit for review through proper channels if those exist, in the mean time:
commit in github: https://github.com/daniellandau/gnome-battery-bench/commit/4113a88efae780dbe2f97794e5a83dd030f95866
patch: http://landau.fi/2015/0001-fix-for-when-have-charge_now-but-no-energy_now.patch
Hmmmm …. my plan for systems that only have charge_now and not energy_now was different – to simply compute an average current and display that and not display an average power.
Compared to your approach the advantages would be a) I don’t think there’s anything requiring a system that has charge_now/full to have voltage_now b) If the battery is reporting things in terms of current, it probably indicates that doing things that way will give the most accurate battery lifetime.
The disadvantage is that it makes it pretty hard to compare to the numbers someone else is talkng about – if other people are discussin that an average backlight consumes 3-4 watts of power, it’s not very friendly to a user if the application shows a consumption of 250mA with the backlight at 5% and 420mA with the backlight at 100%!
I see your patch does leave things using current for time estimates, so I think it’s probably OK to show a computed “average power” if voltage_now is available. How much does voltage_now change on your system from a full battery to an empty one? If it changes a lot, then a problem with your computation is that it is using the voltage_now at the end of the run combined with an average current over the entire run.
I’ve now gone ahead and asked for a bugzilla.gnome.org product for gnome-battery-bench, so that would be my preferred way to submit bugs when that is created now. For now, mailing patches to me at otaylor@fishoup.net is fine.
I have learned;
1) It is important for the CPU/GPU to “sleep”, and this is probably among the most important factors. This is when it truly saves power. Wayland could be great in this case since it is supposed to call for less operations than X.
2) The GPU must work for the graphics. Some turn off the GPU, but this actually consumes more power since the CPU requires more resources than the GPU to perform the tasks.
3) The display consumes very little energy compared to the rest of the hardware. I would not focus at the display at all.
My computers, Thinkpads (a whole bunch of them) consumes much more in Ubuntu than in Windows. The idle in Ubuntu is 12-13w idle and 13-15w when working, while in Windows 6-7w idle and 12-13 when working. There is a constant drain of energy in Ubuntu, while Windows changes drastically depending on what you are doing. Ubuntu for some reasons won’t let the CPU/GPU sleep, as I understand it, and thus is the computer constantly draining power.
I believe the best solution would to make sure that all operations call as little as possible for the CPU/GPU. And probably only to focus at the Wayland session.
What I measure on a pair of recent ultrabooks with GNOME and Fedora (not Unity and Ubuntu) is different. With Fedora the processor generally is spending most of the time in lower power-saving states when idle – the CPU is not a significant user of power when idle. This could be a Unity/GNOME difference. It could be a difference in hardware – CPU technology has evolved over time. But I’d suggest testing with a newly created clean account and no applications running – it may be that you have something configured in your user account which is running away in the background.
On my F20 laptop, the biggest power sucks are Firefox (I have two instances running, at about 10% CPU each, even after sitting idle for ages) and Cinnamon (similar, about 5-10% idle). I don’t have animated web content, so I don’t think it’s that.
Will this project help find why Firefox and Cinnamon are so power hungry?